Why using a env variable instead of a config token ? (i think i know the answer, but i want to see if you think the same as me. And if you do, the issue is more general than this need, and then, should be generalized instead).

Also, documentation must be updated to talk about this one.

My reasons were:

1. It leaves buildozer.spec platform agnostic - at the moment, all the settings are local to the project so you can clone someone's entire project (including buildozer.spec) and run it with no problem. A p4a dir config token would change this by putting system specific config in the file. In contrast, an env var at both ends will give the right behaviour.

2. It fits my use case (which I think would be quite common), since it makes it easy to set the variable globally and to automatically use the same p4a in every project.

3. It matches how p4a handles similar dependencies.

Of course, there are disadvantages to these as well, I honestly didn't know which way would be best.

Why not have a config token that can be superseded by an environment variable if one exists?

That would fix some things, but leaves the minor problem of failures on different system if the env var doesn't exist but the config token does. Of course, you could solve that too by checking if the config token directory exists and cloning p4a if it doesn't. Or maybe that problem isn't important.

I thought about stuff like this, but I didn't like it because it adds an extra layer of complexity and implicit behaviour. I'm not saying it's necessarily a bad idea though! Just that's why I didn't start off that way.

@inclement good. :)

I ended up my thinking at the same point as broush: globally, all the config token could be superseded by env, in the syntax SECTION_TOKEN=VALUE (we could even prefix them with P4A_ to avoid collision).

And then, leave the config token to blank if you don't want to use it. If it's commited with a specific path (using relative path would be good i guess, while make less-sense if it's using the directory of an user for example), then it's up to you to tell the original user to leave it blank, or set the associated env to blank as well.

This way, we have a global approach for overriding all the tokens. :)

I've pushed some changes that give this behaviour. When the ConfigParser is created, buildozer now checks every existing section and token for an env var of the form SECTION_TOKEN, with dots replaced by underscores, and uses it to set the ConfigParser variable if the env var exists. It also checks for an env var when a token is accessed (e.g. with getdefault), in case the section/token didn't exist in the original config but does exist as an env var.

I also added android.p4a_dir as a buildozer token, which can of course be overridden with $ANDROID_P4A_DIR.

Is this method the right way of doing it? My main concern is whether there should be more env checking attached to the token querying of the ConfigParser; at the moment, and environment variable is only checked if the token exists in buildozer.spec or if if is accessed with the monkey-patched get... methods. That means it isn't detected by ConfigParser.has_option, but I don't see a nice way around this without replacing some more ConfigParser methods or adding defaults to the ConfigParser (I don't think there are defaults already?).

This isn't currently a problem (and may never be), as the config is only accessed with getdefault etc. As long as this is always the case, there is no problem.

Anyone have comments on this? I'd like to add documentation and submit it to be merged if the general idea is as you both wanted.

Good!